In many software applications utilizing network communications, key functionality or information is deployed onto a publisher, frequently a computer data publishing source, and users communicate with the data publishing source via various consumer devices such as computers, cell phones, and tablets among other such devices. New events and data changes are processed on the data publishing source and communicated to the consumer devices using various methods with varying degrees of delivery reliability. Modern forms of communications are usually subdivided into two main types: pull or get technology services, where a consumer periodically initiates requests to a data publishing source (i.e. pulling for data), inquiring as to whether new information is available, and push technology services, where a data publishing source initiates the sending of new events from the data publishing source to those consumers that have the right as well as need to receive such updates (i.e. message broadcast to consumers subscribed to receive such messages from the data publishing source).
Respectively, each of these types of communications, when used individually, has serious drawbacks in some mission critical applications. The pull for data provides the reliability of updates including the guarantee of delivery but at the cost of update latency, since a built-in time delay in consumer requests for updates is typically present. In addition, the pull increases utilization of often limited computer network resources, forcing data publishing sources to do wasteful work responding to queries when there was no changes in data. In cases where thousands of consumers are bombarding the data publishing source with periodic requests, this inefficiency will result in a significant data publishing source load. In contrast, the push method, while providing the instantaneous event notification only when there are actual data changes, is not reliable by definition since both consumer and data publishing source may not be not be aware of lost messages. Some approaches that provide a delivery confirmation to the data publishing source with subsequent re-deliveries have not been reliable due to the increased complexity and vulnerability of massive redelivery cycles that tend to clog the delivery network in cases of persistent communication failures.
In many applications currently utilized in the art, consumers stay synchronized with the data publishing source in a push or a pull but not both.
In such application known in the art, the consumer(s) periodically and repeatedly requests the data publishing source to check whether the data publishing source has any new messages for a consumer. This periodic polling from a large number of consumers to the data publishing source induced a very heavy load of unnecessary requests to be processed. In a majority of events, the data publishing source may not even have any data for the consumer but the consumer inefficiently re-loads the data nonetheless.
Another complication that this scheme introduces is that the data are not available in real-time. The consumer has to wait for the next iteration of the periodic pull to receive any messages that may have been generated. In a time-sensitive application, this can introduce delays and cause various negative impacts.
In another application known in the art, a data publishing source may be pushing the data in real-time to the consumer. In this scheme the data publishing source sends the message to the consumers in a send and forget fashion. A significant complication that arises with this mechanism is that reliability is compromised. The real-time push based mechanisms are built on the foundation of persisted channels between the consumer and the data publishing source, which allow the data publishing source to send any message to the consumer when available. This persistent channel can be compromised due to any number of events both known and unknown in the art, leaving the consumer out of sync with the data publishing source.